Ask ten MES vendors whether their platform supports “full genealogy” and all ten will say yes. Ask them to show you the ISA-95 Part 4 object model their genealogy tables are built on, and the conversation gets a lot quieter. That gap — between “we track lot numbers back to raw material” and “we implement the standard’s actual data model” — is where plants get burned during recalls, supplier audits, and multi-vendor MES integrations.
This piece walks through what ISA-95 Part 4 actually specifies, what most off-the-shelf genealogy modules deliver instead, and what schema fields you should demand answers about before you sign a contract or go live.
What ISA-95 Part 4 Actually Is
ISA-95 (formally ANSI/ISA-95, aligned internationally with IEC 62264) is the standard for integrating enterprise systems with control systems — the ERP-to-MES boundary. It’s split into parts, and each part covers a different layer of the problem:
- Part 1 defines the models and terminology — the famous functional hierarchy of business planning, MES, and control.
- Part 2 defines object models and attributes for things like personnel, equipment, material, and process segments.
- Part 3 covers detailed activity models for manufacturing operations management.
- Part 4 defines object models for manufacturing operations management information exchange — and this is where production genealogy actually lives.
Part 4 isn’t a vague set of principles. It’s a concrete, relational schema: entities, attributes, and relationships that describe how a production response (what actually happened on the line) relates to a production schedule (what was supposed to happen), and how both relate to material lots, equipment, personnel, and process segments consumed along the way.
The Genealogy-Relevant Objects
The pieces of Part 4 that matter most for genealogy are the Material Lot, Material Sublot, and Segment Response objects, tied together through Production Response records. In plain terms:
- A Material Lot has an identity, a status, a location, a quantity, and a set of properties — but critically, it also carries assembly relationships to other lots and sublots. This is the actual genealogy link: which lots went into which other lots, and in what proportion or quantity.
- A Material Sublot lets you subdivide a lot without losing traceability — a drum split into totes, a coil slit into sheets — while preserving the parent-child chain.
- A Segment Response captures what happened during a specific process segment: which equipment ran, which personnel were involved, which material lots were consumed and produced, and what parameters were recorded.
- These roll up into a Production Response, which is the actual, as-run record tied back to the as-planned Production Schedule and Production Performance objects.
The key design idea is that genealogy isn’t a separate module bolted onto MES — it’s the natural output of correctly modeling material consumption and production at the segment level. If you model process segments and material lots properly per Part 4, genealogy is a query, not a feature you had to buy separately.
B2MML: The Standard’s XML Skin
B2MML (Business To Manufacturing Markup Language) is the XML schema implementation of the ISA-95 object models, maintained under the standard’s umbrella. It’s not a separate standard — it’s how you actually move Part 4 (and other parts’) objects between systems as structured, validated documents. When someone says “we exchange genealogy data in B2MML,” what they should mean is that their MaterialLot, MaterialAssembly, and SegmentResponse elements carry the required attributes and relationship structures that Part 4 defines, not just an ad hoc XML file with lot numbers in it.
Where Off-the-Shelf MES Genealogy Modules Diverge
Here’s the uncomfortable truth: most commercial MES genealogy features predate serious Part 4 adoption, or were built by teams optimizing for a demo screen — “type in a lot number, see a tree” — rather than for a portable, standards-based data model underneath. The tree view can look identical to a Part 4-compliant system while the underlying schema is completely proprietary.
Common patterns you’ll find when you dig into the actual database or API:
- Flat consumption tables instead of true assembly relationships. Many systems log “lot X was consumed at workorder Y” as a transaction record, without preserving quantity ratios, sublot splits, or multi-level assembly structures the way Part 4’s MaterialLot/MaterialSublot relationships require. That works for a simple forward trace but falls apart on backward genealogy through blending, mixing, or rework operations.
- No process segment linkage. Part 4 ties genealogy to the actual segment response — equipment, personnel, parameters, and time all attached to the same event. Vendor-proprietary models frequently decouple these, so you can find out what material went into a batch but not which equipment run or which operator shift produced it, because that data lives in a different table with a different key structure.
- Vendor-specific identifiers with no standard mapping. Internal surrogate keys instead of the standard’s ID/description/property attribute structure, which makes B2MML export an afterthought — often a translation layer bolted on for integration projects rather than a native representation.
- No support for co-products, by-products, or lot merges/splits as first-class objects. Part 4 explicitly supports these; many MES genealogy modules treat them as edge cases requiring custom scripting.
None of this is necessarily a defect in the product — most MES platforms are doing genealogy well enough for the use case they were sold against. The problem shows up specifically when you need to integrate genealogy data across more than one MES (common after acquisitions, or in multi-plant supply chains), or when an auditor or recall investigator asks a question the UI’s canned reports weren’t built to answer.
Why This Is Biting Plants Now
Recall and audit expectations across FDA-regulated industries and automotive supply chains have gotten sharper about depth of traceability — not just “can you find the lot” but “can you show the full assembly chain, the process parameters, and the equipment/personnel context in one coherent record, quickly, across systems.” That’s exactly the query pattern Part 4’s model was built to support, and exactly the query pattern proprietary genealogy schemas struggle with once you need to join across a supplier’s MES and your own, or across two plants running different MES platforms after a merger. The rework isn’t rewriting genealogy logic from scratch — it’s building a mapping layer to translate one vendor’s proprietary lot-relationship model into something a second system, or an auditor’s data request, can actually consume.
What to Demand Before Go-Live
During evaluation, don’t accept “yes, we do genealogy” as an answer. Ask for specifics:
- Can the system export material lot assembly relationships (parent-child, with quantities) as valid B2MML, not just a proprietary XML or CSV dump?
- Does a single genealogy query return the linked process segment data — equipment, personnel, and parameters — or do you need a separate join against another module?
- How are lot splits, merges, and co-products modeled? Ask for the actual schema, not the UI screenshot.
- Can the system represent multi-level genealogy (a sub-assembly that itself has traced components) without custom development?
- If you have or anticipate a second MES in the environment (through acquisition, a different plant, or a supplier’s system), ask specifically how genealogy data will be reconciled between the two data models — this is where the real cost shows up.
The honest answer from a vendor might be that they support genealogy well within their own ecosystem but haven’t built a native B2MML-conformant model — and that can be a perfectly reasonable tradeoff for a single-plant, single-vendor environment. What you want to avoid is discovering that tradeoff during a recall investigation instead of during the RFP.
The Practical Takeaway
ISA-95 Part 4 isn’t academic plumbing — it’s a genuinely useful blueprint for what a genealogy record needs to contain to survive contact with an auditor or a second system. Treat “genealogy module” as a marketing term until you’ve seen the schema. The plants that don’t get surprised later are the ones who asked to see the data model before they asked to see the demo.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
